REMARKS 



Claims 1-29 are pending in this application. Claims 1-29 were rejected. Claims 1, 6-8, 
12-15, 20-22 and 26-29 (including all independent claims) were rejected under 35 U.S.C. § 103 
as being allegedly unpatentable over Alexander Jr. et al., U.S. Patent No. 6,501,749 
("Alexander") in view of Guruprasad, U.S. Patent No. 7,002,927 ("Guruprasad"). Claims 5 and 
19 were rejected under 35 U.S.C. § 103 as being allegedly unpatentable over Alexander in view 
of Guruprasad and U.S. Patent Publication No. 2006/0067317 ("Engstrand"). Claims 9-11 and 
23-25 were rejected under 35 U.S.C. § 103 as being allegedly unpatentable over Alexander in 
view of Guruprasad and U.S. Patent No. 5,081,621 ("Sugimoto"). 

These rejections are respectfully traversed. The Applicants respectfully submit that the 
previously-presented claims were not obvious over the art relied upon. However, in order to 
facilitate prosecution, claims 1,15 and 29 have been amended without prejudice to subsequent 
presentation of these claims in a continuing or in a related application. Applicants have amended 
the phrase "plurality of tunnels across a computer network" in the independent claims to recite 
instead "plurality of tunnels across a public computer network" to make explicit that the 
computer network at issue is a public one. This amendment is supported by the Specification, 
for example, at paragraph [00170 and [0018]. 

The independent claims, as amended, now recite "creating a link aggregation comprising 
a plurality of tunnels across a public computer network to connect a first computer to a second 
computer, the plurality of tunnels including a tunnel for each link in the link aggregation." The 
Applicants respectfully submit that the claim elements "a plurality of tunnels across a public 
computer network" and "the plurality of tunnels including a tunnel for each link in the link 
aggregation" are not taught by Alexander and Guruprasad, either alone or in combination. 

Specifically, Alexander, the primary reference, describes a system for handling one-to- 
many transmissions for link aggregation. It states: "In designing a switch that supports 
transmission of multicast or broadcast traffic, there are two general approaches that can be used 
to transmit packets within the switch to their outbound (egress) ports. The first solution is to 
simply send the packet once to each outbound port. The second solution is to use a one-to-many 
solution that allows one transmit with multiple destinations. (Alexander, col. 1, Ins. 55-61 
(emphasis added).) "In architectures that support a one-to-many transmission, transmitting 
traffic out more than one outbound port (multi-destination traffic) is fairly simple until the egress 
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ports need to handle the frames differently based on criteria such as a link aggregation virtual 
interface." (Alexander, Col. 2, Ins. 1-5). "The specific problem addressed here is how to use a 
one-to-many transmit strategy for link aggregation." (Alexander, col. 2, Ins. 14-27.) 

However, Alexander does not teach a "plurality of tunnels across a public computer 
network." In fact, Alexander does not teach a public computer network or tunneling across a 
public computer network in any way. Figure 4 of Alexander depicts the system described in 
Alexander: Figure 4 shows an ingress port and egress ports all contained within a single switch 
401: 




As described in Alexander and depicted in Figure 4 of Alexander, Alexander addresses 
how to route traffic within a particular switch (between the ingress and egress ports) to achieve 
one-to-many transmissions. 

By contrast, various embodiments of the present application seek to address certain 
problems associated with transmitting link aggregations across a public computer network, such 
as an internet service provider (ISP) network. Various embodiments relate to transmitting data 
across a "public computer network." As discussed in the Specification, in "data transmission . . . 
between geographically separated customer sites", a business customer may wish to "connect 
via [an Intemet service provider] ISP to [the] same business located at another site." 
(Specification, [0001] and [0017].). In such situations, "L2PT allows switches on the inbound 
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side of the ISP infrastructure to encapsulate protocol packets with a special MAC address and 
send them across the ISP infrastructure. Edge switches on the outbound side of the ISP 

infrastructure decapsulate the protocol packets and send them to a customer network 

Thus, the ISP infrastructure is transparent to the customer network." (Specification, [0007].) "A 
significant challenge overcome by the present invention is to process the bundle of connections 
from one side of an ISP network to the other." (Specification, [0017].) As the Examiner 
correctly points out, "tunneling encapsulates packets with a different protocol so they can be 
transmitted over to [sic] the network operating under that different protocol." (Office Action, 
page 2.) 

Alexander, as described above, does not discuss tunneling. It addresses a fundamentally 
different problem: its focus is on what occurs within a particular switching device. It does not 
mention a "public computer network," much less "creating a link aggregation comprising a 
plurality of tunnels across a public computer network." Based on at least the above, the 
Applicants respectfully submit that Alexander does not teach "creating a link aggregation 
comprising a plurality of tunnels across a public computer network to connect a first computer to 
a second computer, the plurality of tunnels including a tunnel for each link in the link 
aggregation." 

Guruprasad, the secondary reference, fails to cure the deficiencies of Alexander. The 
Examiner seeks to use Guruprasad to establish "that the links are tunnels" (Office Action, page 
4). However, Guruprasad does not appear to discuss tunneling across a public computer 
network. The word "tunnel" does at least appear in Guruprasad; however, Guruprasad does not 
teach tunneling across a public computer network. Guruprasad states: 

According to an embodiment of the present invention, a 
method is provided for automatic aggregation of a plurality 30 
of virtual paths emanating from a first switch. The method 
includes automatically discovering and identifying portions 
of the virtual paths that run parallel to one another, e.g*, 
through the same set of switches up to a common terminat- 
ing switch at which the paths diverge or terminate, as a 35 
candidate path set for aggregation, constructing a tunnel 
path along this set of paths all the way between the first 
switch and the terminating switch, and aggregating the 
parallel portions identified by the path set into the tunnel. 

( 

Gviruprasad, col. 3, Ins. 12-39.) 
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As best understood by Applicants, Guruprasad's "tunneling" relates to combining a group 
of paths into a "tunnel path". It does not relate to encapsulating packets with a different protocol 
so they can be transmitted over a different network. {See Guruprasad, col. 3, Ins, 59 to col. 4, In. 
16, and discussion of tunneling at Office Action, page 2.) Guruprasad does not mention a 
"public computer network." 

Accordingly, the Applicants respectfully submit that the claim elements "creating a link 
aggregation comprising a plurality of tunnels across a public computer network" and "the 
plurality of tunnels including a tunnel for each link in the link aggregation" variably recited in 
claims 1,15 and 29 are not taught by Alexander or Guruprasad, either alone or in combination. 
For at least the above reasons, the Applicants respectfully request that the Examiner withdraw 
the rejections of independent claims 1,15 and 19, and their dependent claims. 

CONCLUSION 

For at least the above reasons, the Applicants believe all claims now pending in this 
application are in condition for allowance. The Applicants therefore respectfully request that a 
timely Notice of Allowance be issued in this case. Should the Examiner believe a telephone 
conference would expedite prosecution of this application, please contact the undersigned at the 
telephone number set forth below. 

The Commissioner is hereby authorized to charge any additional fees, including any 
extension fees, which may be required or credit any overpayment directly to the account of the 
undersigned. No. 50-4480 (Order No.CISCP586). 

Respectfully submitted. 

Weaver Austin Villeneuve & Sampson LLP 

/Roger S. Sampson/ 

Roger S. Sampson 
Registration No. 44,3 14 

P.O. Box 70250 
Oakland, CA 94612-0250 
(510) 663-1100 
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